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I. Introduction 



On 17 Sept 71 Dick Clayton and Robin Frith presented *>-.eir 
views on OS/45 to the OS/4 5 group. ' " 

Since that time we have reviewed the notes of the 17 Sopt 
71 rr.ee ting, added new inputs, and have investiqated com- 
petitive systems. As a result, we have begun to acaiir.- 
a bias as to the orqanization of OS/45. This oaner ure- 
sents the market orientation that has resulted from this 
bias and details the most current definition of OS/45. 
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II. Proorammers Overview of the PDP-11/4 5 

The system programmer contemplating the design of an 
operating system for the 11/45 has two classes of 
problems to resolve: 

1) the price range of possible configurations, and 

2) several new hardware capabilities 

The 11/4 5 has a remarkable range of potential prices: 

$20,000-$300,000. We cannot ignore the low end 
because we can expect competition in this range from 
IBM's first mini -computer, the System/?. At the upoer 
end, even though our price/ performance ratio humbles our 
competitors, we must deal with the IBM 1130 and 1800 
and their immense software library. In addition to the 
cliallenge of duvising a system which has upward compat- 
abilaty ever a price range which varies by an order of 
magnitude, the Evrtems designer must contend with tiiroo 
new hardware options: 

♦Memory hierarchies (memories with different speeds) ; 
* Independence of instruction and data space, and 
•Segmentation. 

Complete understanding of how to properly use these 
features has barely emerged from a research environment, 
yet we must make intelligent use of them in a production 
system. 

To provide reasonable solution to these challenges will 
require a design phase pursued to an unusual depth of 
detail; else we run the risk of rendering the new hardware 
features either unuseable or not cost effective. Pro- 
viding a software system whose facilities compliment those 
of the machine itself will depend on development of a 
design which demonstrates we have indeed mastered the 
requirements of configuration flexibility and innovative 
hardware. 



f 
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III. The 11/45 Marketplace ~ Developing a Worka ble Image 
ot our Customers — 

A designer of any product must have orior to any desiqn 
activity a distinct image of the individuals to whtjm he 
expects to sell his product. The data processing marki>t- 
place has five identifiable concentrations which reflect 
market needs*. 

1) Real Time 

2) Scientific Batch 

3) Time Sharing 

4) Commercial Batch 

5) Number Crunching 

Let us eliminate item 5) from consideration immediately 
as inappropriate to the 11/45. The remaining four items 
represent the order of market priorities as specified by 
Dick Clayton and Robin Frith during our 17 Sept 71 meeting. 
During the same meeting Dick Clayton specified the follow- 
ing framework within which we should define 08/45: 

1) Software support for the floating point unit and 
the segmentation unit should exist by July 1972. 

2) We should announce OS/45 by June 1972 and deliver 

o\ ii/^r^^?*' the second Quarter of calender year 1973. 

3) OS/45 should unify PDP-11 software. 

In addition, we have assumed that OS/45 will consume 
between 18 and 25 man-years of effort. Using the assumed 
manpower estimates it does not seem possible to attempt 
to satisfy the needs of the time sharing or commercial 
batch marketplace. 

In commercial batch, DEC must compete directly against 
IBM and in a marketplace where IBM has no peer. We 
simply do not have the time or resources to design and 
implement an operating system for the 11/45 that would 
compete effectively against IBMfe offerings. And even if 
we could produce such a system, does DEC presently have 
the sales and system force necessary to sell and service 
the ccanmercial market? Current inputs indicate in the 
negative, and« hence, we recommend rejection of orienting 
OS/45 toward commercial batch. 



♦Identifiable in the sanse that their overlap does not 
result in a complete merging of the end user needs. 
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From the above we can extract the foUowma composite 
of the OS/45 customer population: 

He either already uses or has under consideration 
an IBM System/7, 1130, or 1800. His application 
requires only a subset of IBM's software for these 
machines. And finally, the existence of competi- 
tive equipment which has between three and five 
tines the cost performance of the equivalent IBM 
system provides our hypothetical customer with 
sufficient reason not to remain with or choose 
IBM. 

Of course, the computer marketplace does not exist 
entirely under the aegis of IBM and DEC, but we contend 
that if we can produce a software system which signi- 
ficantly impacts System/7, 1130, and 1800 sales, then 
we will have more than nullified the offerings of XDS, 
Hewlett-Packard, Data General, SEL, EMR, Varian, and 
Interdata all of whom offer real-time systems in the 
16 bit class. 
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Ml these facts lead us to one inevitable conclusion: 
make sure OS/4 5 provides a set of scientific batch 
facilities that makes it possible for us to capture 
10*i of the potential 1130 market. 

This brings us to the top priori tv on the list ~ Real 
Tine. As with the 1130, we will confine ourselves to 
IBM. In real time, IBM offers the system/7, the 1800, 
and the 360/44. The 360/44 really belongs in a differ- 
ent class of equipment (Decsystem 10) so we will concen- 
trate on System/7 and the 1800. First the 1800. 

IBM has a total of 563 1800's installed or on order at 
an average system price of $300,000. The 1800 hardware 
represents little or no competition for the 11/45. IBM 
does, however, tend to overwhelm their competition with 
software, which includes two systems (MPX and TSX) capable 
of running, simultaneously, real time in the foreground 
ana batch in the background. As with the 1130, even the ugh 
we can t hope to provide all the software IBM does, the 
task of selecting a competitive subset appears achievab e. 
And even 10% of a $200,000,000 market would handsomely 
repay our investment (and hopefully we would capture much 
more than 10% of this market) . 

Unlike the 1800, System/7 represents an insidious rather 
than a direct challenge to the 11/45, Only the smallest 
System/7 configurations offer any competition for the 
11/45. In most of these small configurations, we suspecc, 
an 11/20 would provide a more cost effective solution. 
Regardless of how DEC counters the threat of System/7, 
counter-it it must. IBMs track record for customer 
loyalty provides little comfort to the DEC salesmen 
attempting to replace a System/7* with a PDP-11. Once 
in the door with a system/ 7, add-on equipment and growth 
to larger systems will go to IBM by default; System/7 
will lead to 1130's and 1800's. (Indeed, the initial 
System/7 marketing thrust practically requires that the 
user already have an 1130, 1800 or 360) . 

To compete with IBM in the real time market we suggest 
that OS/45 provide a real time capability that spans the 
entire price range of the 11/45 with upward compatibility 
of object programs provided across the entire range of 
possible configurations. 



» We should not delude ourselves regarding the potential of 
System/7. IBM has consistently enhanced products to meet 
the threat of competition - How about segmentation reqxsters 
on System/7? 
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A time sharing orientation also seems unachievable on 
schedule with available resources. The pursuit of an 
11/4 5 time sharing system also seems unadvisable if 
DEC decides to produce a small version of the 10. Any 
attempt to provide a multi* language time sharing system 
for the 11/45 (we already have a single language system 
in RSTS) runs the risk of colliding with the introduction 
of the small 10. Software production costs continue t;^ 
rise and hardware costs continue to decline. And we have 
little assurance that the total cost of an 11/45 tiine 
sharing system (hardware plus software) will not exceed 
the total cost of the small 10. 

The existence of RSTS and the relatively modest cost 
involved in altering RSTS to take advantage of the fpp 
and segmentation provides additional reason for avoidinq 
a time sharing orientation for OS/4 5. if the future ot 
time sharing depends on applications packages, and if basic 
Plus has sufficient language constructs to build most ap- 
plications packages suited to the 11/4 5, then what incre- 
mental gain can we expect by producing a multi-language 
system? We cannot answer this question factually, but 
doubt that the incremental gain can offset the software 
development costs. Thus, we recommend rejection of a 
multi- language time sharing organization for OS/4 5. 

We now arrive at scientific batch. We define this as 
batch streaming of FORTRAN programs and cite the 1130 
Disk Monitor as the type of facility against which we 
can expect to compete. 

IBM has installed or on order 3800 1130s at an average 
price of $90,000.* It would not surprise us if the 11/4 5 
has a cost/performance ratio five times that of the 
equivalent 1130. 

Dick Clayton projects 1000 11/45 sales over the life 
of the system. If we can capture 10% of IBM's 1130s 
as a result of providing a con^etitive scientific batch 
system, then we would help him achieve 1/3 of his goal. 

Furthermore, the 1130 customer does not need the prac- 
tically dimensionless volumes of software of the commercial 
market. These users rely on FORTRAN heavily (making it 
possible for him to convert at modest cost) . And the size 
and cost of the 1130 itself places a practical limit on 
type of applications it can support. 

♦September 1971 issue of Computer and Automation . 
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In ;. .;-aivn:y, marketing will have .. -oi- • .i li:^b 
i'PP -\i\ii aegmentation by July '72, cjt a- ■ .est of 
^5or t additional software proliferation; '. v .^ill have 
.ir< -.nnounceable definition of OS/45 by • e' '72, and 
tlic announced OS/45 will take sicjnifica-t steps toward 
un if vino PDP-11 software. 

:.^i .-. return now to a more explicit definition of 
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IV. Satisfying Marketing's Requireroents 

Dick. Clayton and Robin Frith specified three requircnents 
for OS/45: 

1) Software support for FPP 6 Segmentation Unit 
by July 1972. 

2) Announcement of OS/ 4 5 by June '72 for delivery 
during the second quarter of 1973. 

3) Unification of PDP-11 software. 

Before discussing details of OS/45 (in ssction III we 
established a customer profile; we have y«t to describe 
how we intend to satisfy their requirements) let's excmine 
each of these points and how we can satisfy them. 

1) Local modification to existing software represents 
the roost reasonable approach to meeting this re- 
qui.rement. RSTS can at modest cost make use of 
botJi the Segmentation Unit and the FPP, DOS plans 
also exist to make use of the segmentation unit. 

At*:empting to rush the design and implementation of 
th<^ OS/45 Kernel in order to permit DOS t RSTS to 
convert in time to meet the July '72 deadline seems 
unwarranted* such haste will jeopardize both the July 
'72 date and the consistency and coherence of OS/4 5 
over the longer term. Of course, by making 11/4 5 
oriented modifications to DOS and RSTS, we oay the 
pr.-ce of continuing the proliferation of so'ftware 
systems for the 11 line. 

2) Wi;hout a dovibt the OS/45 group will have a system 
defined for announcement by June '72, but the scope 
of the system depends on available resources (Dick 
Clayton has already specified delivery reauirements) 



3) Initially the objective of xinifying PDP-11 software 
wall not happen. DOS and RSTS will evolve independ- 
ei^tly, and it does not seem advisable to attanpt to 
prevent this. 

But as we will describe shortly, OS/45 as it evolves 
will make every attempt to reclaim as much existing 
]1 software as possible. The OS/45 design will provide 
isers with a system covering a broad range of configura- 
tions, programming facilities for real time and batch, 
and will disrupt existing user interfaces only where 
absolutely essential. 



Having Identified our Customers, How do we Satisfy 

Their Needs? ~ *" 02^7 

We have identified our users in Section lit. They have 
real time requirements and scientific batch requirements. 
At the low end we must block the purchase of a System/7; 
at the high end we must overcome the presumed user benefits 
of IBM's vast software library. 

We believe we can satisfy these requirements, by offering 
a system which provides upward compatibility across the 
entire price range which is available on the 11/45 (20,000- 
300,000). This IBM cannot do) movement within System/?, 
1800, and 1130 requires a conversion effort; OS/45 will 
not. 

Itow, it turns out, that Segmentation provides an efficient 
hardware mechanism for implementing a system which can 
covar the configuration range under discussion. With seg- 
BMUitation hardware and a set of software standards, we can 
specify a cascade of hardware configurations each of which 
requires additional hardware, in order to acquire more 
elaborate services; all the while we guarantee complete 
upward compatibility. The success of this approach depends 
on a careful definition of the user virtual machine. ' 

Basically this means that the user of an OS/ 4 5 system has | 
a well defined set of facilities he may use. These facil- 
ities consist of a subset of the PDP-11 instruction set 
and a collection of service routines. As configurations 
grow in complexity, the set of services expands corres.'^ 
pondingly, but we always provide complete upward coa^ati- 
bility. This scheme implies that every OS/45 configuration 
operates with a set of supervisory code. This code, of 
course* will vary considerably on different configuration 
classes and in every case appears transparent to the user. 
Let's examine some possible configurations:* 

Hardware 
i) 11/45** 

4K-12K 

TTY 

Foreground only. 

Small systems suffer from the lack of adequate 
program preparation facilities. If you can 
prepare your programs on a larger systcsi often 
4X suffices to meet the needs of the application. 
IBM has solved this problem for System/? by providing host 
preparation facilities on larger equipment 
(1130, 1800, 360) . With this technique they pro- 
vide a Macro system called MSP/7. We see no 
reason why we cannot do the same. Indeed, if we 
intend to meet the threat of System/7, host prep- 
aration facilities se«n essential. 



♦These represent examples of possible configurations; the reader 
should not accept them literally . 
**We intend to investigate full ll/20 compatibility and issue a 
memo describing our conclusions. 
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2) 11713 

12K-16K 
TTY 

Software 

Disk, tape, etc. 

DOS subset 

INDAC/ll 

Overlay Facilities 

Fortran 

Host preparation eliminated 
Foreground only. 

Hardware 

3) TTTn 

16K-24K 

TTY 

Disk, tape 

Segmentation 

Software 

Same as 2, plus; 

m!in?f?;!2'^ ""?^^ background stream. System 
SnrbJtJJSr^S:?!**'" '^°'*^'°" ^^-- foreground 
partittoUf.*"*^ background operate in fixed 

Hardware 
4) iiame hardware as 
3)but with 28K 

Software 
same as 3) plus 
support of background 
jobs whose size ex- 
ceeds that of physically 
available core. 

Hardware 
5) same as 3 but with 32K 

Software 

^Tplus 

shared code 

Multiple background jobs. 

Index Sequential file system. 

Hardware 
fi) b but with 40K 

Software 
S>) plus 

Multiple Foreground jobs (Individually proteet«l) . 



"■ A 
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Once v/e define the basic user virtual machine we can 
determine exactly which particular configuration classes 
available rasources permit us to produce. Furthermore, 
with well defined configuration classe:% the product 
manager has available to him a shopping list that en- 
ables him to make cost trade-offs far more reasonably 
than he can at present. It also makes the programming 
departmenr more aware of the incremental costs involved 
as you move up the seale in system complexity. 



yr^ , 
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VI. Sxmunary and Conclusions 

If DEC continues to grow it must eventually increase its 
business at the expense of IBM. To accomplish this 
traditionally unaccoroplishable feat, we have sugqested 
a software plan for OS/45 which confronts IBM where they 
appear most vulnerable - real time and scientific batch. 

IBM, with present offerings, provides zero hardware com- 
petition for the 11/45. To counter IBM's software 
libraries, OS/4 5 takes an approach IBM cannot easily 
counter : upward compatibility within a price range that 
completely covers IBM's real time offerings in the 16 
bit class. 
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